<?php
/**
 * <https://y.st./>
 * Copyright © 2018 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => "Packets",
	'<{subtitle}>' => 'Written in <span title="Communications and Networking">CS 2204</span> by <a href="https://y.st./">Alex Yst</a>, finalised on 2018-05-30',
	'<{copyright year}>' => '2018',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<h2>Maximum packet lifetime</h2>
<p>
	The assignment asks us this:
</p>
<blockquote>
	<p>
		Why does the maximum packet lifetime have to be large enough to ensure that not only the packet but also its acknowledgments (sic) have disappeared?
	</p>
</blockquote>
<p>
	This question makes no sense.
	The maximum packet lifetime <strong>*defines*</strong> the point at which we insure a packet has disappeared.
	No matter what the maximum packet lifetime is, if the packet is being handled by compliant routers, the packet will be dropped once it hits that age (Dordal, 2014).
	Likewise, when we define this maximum packet lifetime, we <strong>*don&apos;t*</strong> ensure that acknowledgements will be dropped by then.
	As delivery of the packet will take a non-zero amount of time, the lifespan of the acknowledgement will necessarily be offset.
	The packet might even be delivered just before it expires, effectively <strong>*doubling*</strong> the amount of time we may have to wait for the acknowledgement and have it still arrive before its own expiration.
</p>
<p>
	There has to be a mistake in the question.
	My guess is that it was intended to ask why the TIME_WAIT state needs to be long enough to ensure not only the packet, but its acknowledgements have have disappeared.
	In this case, it&apos;s to make sure there are no stray packets (including acknowledgement packets) from this instance of the connection that might make their way into a future instance of the connection.
	The chances of one of these delayed packets having the correct sequence number to be mistaken as a packet from the then-current instance of the connection upon arrival is minimal, but it&apos;s still worth trying to clear the line at the end of each connection instance.
</p>
<h2>The Nagle algorithm on a congested network</h2>
<p>
	The Nagle algorithm seeks to reduce the number of packets being sent, which in theory, should help with congestion problems.
	After all, all the same payload data gets through, but only one set of headers is needed for what would otherwise be several packets (Dordal, 2014).
	However, it still has disadvantages.
	First, on a congested network, the Nagle algorithm will cause less congestion to be generated, but the application using the Nagle algorithm won&apos;t be able to get its packets sent as quickly, so they won&apos;t be received as quickly.
	With the Nagle algorithm already slowing down transmission, congestion adds to this to make it worse.
	To top it off, acknowledgements will take longer to reach the application using the Nagle algorithm, causing said application to bundle even more of the would-be-tiny-packets into the bigger packet, slowing down transmission further.
	Additionally, these larger packets will tie up the line longer than the small packets would, so no other packets can be slipped between the small packets in the queues and on the line.
</p>
<p>
	Despite these two issues though, I do think the Nagle algorithm does more good than harm on a congested network.
</p>
<h2>Data-less packets on an established connection</h2>
<p>
	Obviously, packets with no payload data are used during connection instantiation and termination.
	However, they&apos;re also used during the normal operation of an established connection (Dordal, 2014).
</p>
<p>
	The main example of this would be acknowledgement packets.
	Connections are often very one-sided, with one side transmitting all the data and the other end remaining silent.
	As the receiving end has no data to send, it can&apos;t include the acknowledgements in its own data-carrying packets.
	Instead, it has to send data-less packets consisting only of headers in order to acknowledge how much data has been successfully received.
</p>
<p>
	Another case of data-less packets is the polling packets sent by a data-sending node.
	If the receiving node has reduced the windows size to zero, the sending node will periodically send data-less polling packets to check to see if the window size is still zero.
</p>
<h2>FIN_WAIT_1</h2>
<p>
	FIN_WAIT_1 is stage in which the application has sent its own FIN packet, but has not yet received a response (Dordal, 2014).
	Under ideal conditions, this state lasts but a moment, as data transmission over the network these days is almost instantaneous for packets that small.
	If connections in this state are piling up, there&apos;s probably either heavy network congestion or an outright network disconnect to blame.
</p>
<h2>FIN_WAIT_2</h2>
<p>
	FIN_WAIT_2 is the stage in which a node has sent its FIN packet, has received acknowledgement of that FIN packet, and has not yet received a FIN packet from the other node (Dordal, 2014).
	If you see several connections are in this state, you&apos;re probably working on a machine that is receiving data, but not sending any.
	With how quick data can be transferred, having multiple connections in this state suggests either network congestion or large data files.
	For example, if I was trying to download a live Debian $a[ISO] over $a[HTTP], my client machine would likely send its own FIN packet in order to make sure the server wasn&apos;t the one that had to go into the TIMEWAIT state once the connection terminated, then would stay in the FIN_WAIT_2 state while receiving the file data.
	As the file size is enormous, the connection on my client end would be stuck lingering in the FIN_WAIT_2 state for a considerable amount of time.
	Now, if I tried downloading several other large files before this first file download concluded, I&apos;d end up with more connections lingering in the FIN_WAIT_2 state as well.
</p>
<div class="APA_references">
	<h2>References:</h2>
	<p>
		Dordal, P. (2014). 12 TCP Transport - An Introduction to Computer Networks, edition 1.9.10. Retrieved from <a href="https://intronetworks.cs.luc.edu/current/html/tcp.html#tcp-state-diagram"><code>https://intronetworks.cs.luc.edu/current/html/tcp.html#tcp-state-diagram</code></a>
	</p>
</div>
END
);
